|
|
This document describes how you can use the SessionParameterStore API's as a persistent store for session related data in your business processes.
The SessionParameterStore enables the developer to transfer information between e.g. an EventHandler and a PageGenerator that is not called directly by the EventHandler.
This can for example be relevant if you have a wizard style application, where each PageGenerator has a separate "Next" event, in which the information provided by the user on the page is gathered and validated - but where the information won't be used until the "Finish" event on the final page of the wizard.
In a normal GUI wizard, you can solve this case by letting each "Next" event write the information to memory - and let the "Finish" event read from memory.
However, in a WebsydianExpress application, each request is handled by a random application service job - so there is no way to ensure that the "Next" events and the "Finish" event are handled by the same job. This means that you can't use a memory-based store to transfer information from the "Next" to the "Finish" events.
The SessionParameterStore provides a database store for session related data that can be used to store data that is to be used be subsequent requests for the session.
Each record in the store contains 4 fields:
This is the unique identification of the session.
When you save a parameter, you will always do so for a session. In most cases, your business process will need to save this for the current session. You can retrieve this by calling: APIServer.Session.ServerGetCurrentSessionID.
This provides a way to make logical groupings of the parameters stored for a session. The aim of this subdivision is to prevent side-effects where several business processes uses a parameter with the same name. When saving a parameter, you must always specify a namespace.
One guideline for assigning a namespace is that if the parameters are used by one specific business process, then using the implementation name as the namespace (or the start of the namespace) can be a good idea.
By adding a sequence to the namespace, you can also use the parameter namespace to distinguish between two different instances of the same functionality for the same session.
The APIs: DeleteAllForSessionNamespace and GetAllForSessionNamespace allow you to handle all parameters for a session/namespace combination. This means that if you have a set of parameters that has the same lifecycle - then it is normally beneficial to let them have the same namespace.
The data is stored as name/value pairs specified by these fields.
The WSYAPI model contains a set of APIs that can be used to store, retrieve, and remove parameters from the SessionParameterStore.
Online documentation - WebsydianExpress v3.5